Zum Hauptinhalt springen

FAQ - E-Mails lassen sich nicht öffnen – Prüf- und Behebungsanleitung

(Stand: 08/2026)

Verfügbar in Subscription: Core · Pro · Ultimate

Verfügbar ab Release: 2.0

Betrifft:

  • 🖥️ IT / Technik
  • ⚙️ Administration

Frage​

Warum lassen sich E-Mails mit Bildern im NEXOWARE c-entron ERP ServiceBoard nicht öffnen oder laden nur sehr langsam, und wie kann die IT-Administration die Ursache selbst eingrenzen und beheben?

Kurzantwort​

Ursache ist fast immer eine blockierte oder zu früh unterbrochene WebSocket-Verbindung zwischen Browser und Server (/_blazor) — meist durch einen Reverse Proxy, ein Gateway, eine Firewall oder einen Virenscanner mit HTTP-Prüfung. Ohne funktionierende WebSocket-Verbindung fällt das NEXOWARE c-entron ERP ServiceBoard auf ein langsameres Ersatzverfahren zurück, das bei umfangreichen E-Mails (viele eingebettete Bilder, teils mehrere MB) an Größen- oder Zeitgrenzen scheitert.

Lösung / Überblick​

Selbsttest in zwei Minuten (kein Login im NEXOWARE c-entron ERP ServiceBoard nötig, die Anmeldeseite genügt):

  1. NEXOWARE c-entron ERP ServiceBoard im Browser öffnen.
  2. Entwicklerwerkzeuge starten (Taste F12).
  3. Auf den Reiter Netzwerk wechseln.
  4. Die Seite neu laden (F5).
  5. Im Filterfeld _blazor eingeben.

Bewertung:

BeobachtungBedeutung
Ein Eintrag _blazor mit Status 101WebSocket funktioniert — Verbindung in Ordnung
Kein Eintrag mit Status 101, stattdessen eine fortlaufende Kette von Anfragen an _blazor?id=…WebSocket wird blockiert — Ursache gefunden

Ergänzend zeigt der Reiter Konsole im Fehlerfall eine Meldung, die den Rückfall auf das Ersatzverfahren („Long Polling") benennt. Zusätzliches Indiz: Melde dich mit einem Benutzer mit dem Recht Einstellungen an und öffne das Dashboard — erscheint dort ein Warnhinweis zur Verbindung, stützt das den Befund. Maßgeblich bleibt aber der Netzwerk-Test oben.

Vier Anforderungen an die Infrastruktur (bitte prüfen):

  • WebSocket-Verbindungen werden durchgelassen
  • Leerlauf-Timeout mindestens 100 Sekunden
  • Keine Zwischenspeicherung und keine Größenbegrenzung für Antworten auf /_blazor
  • Bei mehreren Servern: Sitzungsbindung („Sticky Sessions") aktiv

Anforderung 1 ist in der Praxis in den meisten Fällen die entscheidende.

Wichtig bei TLS-Terminierung am Proxy: Wenn der Proxy HTTPS entgegennimmt und intern per HTTP weiterleitet, muss der Header X-Forwarded-Proto den tatsächlich vom Browser genutzten Wert tragen. Ein falscher Wert erzeugt Weiterleitungsschleifen, die wie ein völlig anderer Fehler aussehen. Gleiches gilt für den Host-Header: er muss den Port enthalten, sonst gehen Weiterleitungen der Anwendung ins Leere.

Konfiguration nach Plattform

Microsoft IIS mit Application Request Routing​

Der häufigste Befund auf Windows-Servern: das Windows-Feature „WebSocket-Protokoll" ist nicht installiert. Ohne dieses Feature reicht IIS WebSocket-Verbindungen grundsätzlich nicht weiter, unabhängig von der übrigen Konfiguration.

  1. Server-Manager → Rollen und Features hinzufügen → Webserver (IIS) → Anwendungsentwicklung → WebSocket-Protokoll installieren.
  2. In der Website-Konfiguration sicherstellen, dass WebSockets nicht deaktiviert sind:
<system.webServer>
  <webSocket enabled="true" />
</system.webServer>
  1. In den Proxy-Einstellungen von Application Request Routing:
    • Response buffer threshold auf 0 setzen (deaktiviert die Zwischenspeicherung),
    • Time-out auf mindestens 100 Sekunden.

nginx​

Entscheidend sind die beiden Upgrade-Zeilen. Fehlen sie, wird der Header nicht weitergegeben und die WebSocket-Verbindung scheitert.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location / {
    proxy_pass http://serviceboard-host:8050;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    # Muss den Port enthalten, sonst gehen Weiterleitungen ins Leere.
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_buffering off;
    proxy_read_timeout 100s;
    proxy_send_timeout 100s;
}

Andere Reverse Proxys​

Für Apache, HAProxy, Traefik und vergleichbare Produkte gelten dieselben vier Anforderungen. Beachte dabei, dass der Pfad /_blazor zwei Arten von Anfragen bedient: zunächst einen gewöhnlichen HTTP-Aufruf zum Verbindungsaufbau, danach das WebSocket-Upgrade. Eine Konfiguration, die diesen Pfad ausschließlich auf WebSocket umleitet, bricht den ersten Schritt. Nötig ist eine Weiterleitung, die anhand des Upgrade-Headers unterscheidet.

Virenscanner, Web-Filter, WAF​

Produkte mit HTTP- oder SSL-Prüfung unterbrechen WebSocket-Verbindungen regelmäßig. Nimm den NEXOWARE c-entron ERP ServiceBoard-Host testweise von der Prüfung aus und wiederhole den Selbsttest. Achte dabei besonders auf kurze Leerlauf-Timeouts — manche Produkte verwenden 10 Sekunden als Voreinstellung, was für den Betrieb nicht ausreicht.

Hintergrund​

Häufige Fehler​

Typische Ursachen oder Missverständnisse sind:

  • Das Windows-Feature „WebSocket-Protokoll" ist bei IIS nicht installiert.
  • Die Upgrade-Header-Weiterleitung fehlt bei nginx oder einem anderen Reverse Proxy.
  • Der Leerlauf-Timeout ist zu kurz eingestellt (z. B. Virenscanner-Voreinstellung von 10 Sekunden).
  • Bei mehreren Servern sind keine Sticky Sessions konfiguriert.
  • Der Pfad /_blazor wird ausschließlich auf WebSocket umgeleitet, wodurch der initiale HTTP-Verbindungsaufbau blockiert wird.
  • Bei TLS-Terminierung sind X-Forwarded-Proto oder Host-Header falsch gesetzt.

👉 In diesen Fällen bleibt die WebSocket-Verbindung instabil oder blockiert, bis die Konfiguration entsprechend korrigiert wird.

Tipp​

Wiederhole den Selbsttest nach jeder Anpassung. Erst wenn dort der Eintrag mit Status 101 erscheint, ist die Verbindung in Ordnung. Öffne danach zur Gegenprobe eine umfangreiche E-Mail in einem Ticket — sie sollte ohne Unterbrechung erscheinen.

Verwandte Themen​

Keine verknüpften Themen in der Originalseite hinterlegt.